home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 884 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: maney@mcs.com (Martin J. Maney)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: delete vs incomplete class type
  5. Date: 27 Mar 1996 22:00:11 GMT
  6. Organization: MCSNet Services
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4jcdp0$b3p@Venus.mcs.com>
  9. References: <sjcDownA7.6FA@netcom.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Newsreader: TIN [version 1.2 PL2 (KSD)]
  12. Content-Length: 2628
  13. X-Lines: 54
  14. Originator: clamage@taumet
  15.  
  16. Steven Correll (sjc@netcom.com) wrote:
  17. > What must a conforming compiler do when confronted with this?
  18. >  
  19. >         struct x;
  20. >         struct y;
  21. >  
  22. >         void
  23. >         p(x *arg0, y *arg1)
  24. >           {
  25. >           delete [] arg0;
  26. >           delete arg1;
  27. >           }
  28. >  
  29. > Section 5.3.5 of my 5/95 copy of the draft standard says "If the object
  30. > being deleted has incomplete class type at the point of deletion and the
  31. > class has a non-trivial destructor...the behavior is undefined." Is this
  32. > still true?
  33. >  
  34. > I don't see how a compiler could avoid noticing that it hasn't a clue what
  35. > destructor to invoke at compilation time. Is there a reason (aside from
  36. > encouraging people to migrate to Java) not to require the compiler to
  37. > diagnose this as an error, instead of allowing it to fault at execution
  38.  
  39. I think you have in fact answered your own question, nearly:
  40.  
  41. > time? (Given that x and y might be PODS, I doubt that it's possible to
  42. > defer the solution to execution time, but if it is, then why not define
  43. > the behavior and mandate that it be correct?)
  44.  
  45. I believe it is in fact that the objects might be PODS that makes this 
  46. the only reasonable rule.  For a PODS, one assumes that there is no 
  47. destructor, which is surely trivial, yes?  The problem whcih you go on to 
  48. describe is simply what happens in the general case when a user-defined 
  49. type is deleted without destruction: the destructor function isn't 
  50. invoked, and so side effects don't happen as expected.
  51.  
  52. So why not make this sort of thing ill-formed?  Probably so that PODS can
  53. continue to be used, as in legacy code that has been only partially ported
  54. to C++.  (I'm thinking here of code that's been cleaned up to compile as
  55. C++, and use some of the features such as new/delete, but that hasn't been
  56. redesigned as OO.  Been there, done that, and it was quite worthwhile as
  57. an intermediate step without which the code probaly would have had to
  58. remain in Plain C until it was abandoned.) This accomodates the common C
  59. use of an opaque data structure, which one might reasonably expect to find
  60. used in the very C code that would be a leading candidate for such a move
  61. to C++.  Or so it seems to me.  :-)
  62.  
  63. Now that you've pointed this out, I should have to agree that it would be 
  64. very nice to see compilers diagnose this, but I wouldn't want them to 
  65. reject such a program as ill-formed for reasons that must be obvious.  
  66. Therefore it has to be a "quality of implementation" issue, or perhaps 
  67. even a job for a lint++ tool, since in general one might have to examine 
  68. files that are not normally, nor are intended to be, compiled together.
  69.  
  70.  
  71.  
  72. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  73. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  74. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  75. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  76. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  77.